Deployment of software images is a commonplace activity in modern computing systems; generally speaking, a software image is a structure that encapsulates the content of a mass memory of a computing machine. The software images are suitable to be moved, copied, replicated, protected and profiled in a very simple way. These advantages are clearly perceived when the software images are used in virtual (computing) machines, i.e., emulations by software of physical (computing) machines provided by a virtualisation layer; indeed, in this case whatever virtual machine may be provisioned on-demand by simply instantiating and then booting it from a desired software image. For example, this is particularly useful in cloud (computing) environments, wherein users of a network are allowed to access computing resources (comprising virtual machines) on-demand as services. In this way, the users are relieved from the management of the actual physical resources that are needed to implement the cloud resources (for example, their installation and maintenance); particularly, this provides economies of scale, improved exploitation of the physical resources, and high peak-load capacity. Moreover, the users are now allowed to perform tasks (for example, on a pay-per-use basis) that were not feasible previously because of their cost and complexity (especially for individuals or small companies). The de-coupling of the cloud resources from their implementation provides the illusion of an infinite capacity thereof; moreover, the de-localization of the physical resources implementing the cloud resources enables the users to access them from anywhere.
However, every cloud environment generally requires specific configurations of its virtual machines; a typical example is the setting of their operating systems (for example, with respect to network parameters). Therefore, different software images may be required for deploying a same structure on different cloud environments, even if they use the same virtualization layer.
Alternatively, the same software image may be deployed on different cloud environments, and then specifically configured with a process know as re-activation; the re-activation process may be performed either manually or by means of suitable scripts that are executed automatically at a first bootstrap of the computing machines.
For example, it is possible to boot a (pristine) computing machine from a network. More specifically, a boot loader launches a network boot loader (for example, the PXE) embedded in a network adapter thereof since it does not find any bootable device; the network boot loader exploits a dynamic address service (for example, the DHCP) to obtain a dynamic address, and then downloads a network bootstrap program (for example, the WinPE by Microsoft Corporation, trademarks thereof) providing a minimal operating system. The network bootstrap program applies the required configurations, and then re-boots the computing machine from the actual operating system of the software image.
A different technique is described in US-A-2012/0204173 (the entire disclosure of which is herein incorporated by reference). In this case, a computing device may configure virtual machines (either before or after their booting) by using configuration commands. Logic associated with reading from and writing to the application and operating system files may be encapsulated in a virtual machine module, which may have an Application Programming Interface (API). The computing device may include a memory storing computer code including an access module to access one or more application files and operating system files included in each of the virtual machine image files; the access module may include an operating system extension provided by a Virtual Machine Management System (VMMS) that mounts a virtual machine image file into an operating system as a drive or a directory accessible by code executing within the operating system.
However, the configuration of each software image is generally performed in the same context of the operating system that is used in a production environment thereof; therefore, configuration and usage of the software image are tightly correlated.
In any case, what is configured in the software image and how this configuration occurs are always mixed together.